Multi-threaded FIFO memory with speculative read and write capability

ABSTRACT

Systems and methods storing data for multi-threaded processing permit multiple execution threads to store data in a single first-in first-out (FIFO) memory. Threads are assigned to classes, with each class including one or more threads. Each class may be allocated dedicated entries in the FIFO memory. A class may also be allocated shared entries in the FIFO memory. The shared entries may be used by any thread. Data for a first thread may be stored in the FIFO memory while data for a second thread is read from the FIFO memory, even when the first thread and the second thread are not in the same class. The FIFO memory may include a speculative read and a speculative write capability. The FIFO memory is shared between the threads to conserve die area, however each thread may be executed independently, as if each thread has a dedicated FIFO memory.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation-in-part of co-pending U.S. patentapplication titled, “A Multi-Threaded FIFO Memory Generator,” filed Apr.6, 2006 and having Ser. No. 11/399,247, which is a continuation-in-partof co-pending U.S. patent application titled, “A Multi-Threaded FIFOMemory,” filed Dec. 14, 2005 and Ser. No. 11/304,959. The aforementionedrelated patent applications are herein incorporated by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

Embodiments of the present invention generally relate to automaticgeneration of data storage for multi-threaded processing and, morespecifically, to a multi-threaded first-in first-out (FIFO) memory.

2. Description of the Related Art

Integrated circuits designed to process data typically use FIFO memoriesto store data between processing stages. These FIFO memories may havedifferent widths, depths, and different input and output clockfrequencies. Conventionally, generators that produce synthesizable codehave been used to efficiently produce different variations of FIFOmemories. More recently, multi-threaded processing systems use aseparate FIFO memory to store data for each processing thread. Usingseparate FIFOs permits data for a thread to be accessed independentlyfrom data for another thread. This independence is essential sinceduring multi-threaded processing, each thread may be executed at adifferent rate and data may be stored in or read from the FIFOs atdifferent rates. However, using separate FIFOs for each thread uses moredie area than using a single FIFO to store data for multiple threads.The conventional generators do not produce synthesizable code for a FIFOthat may be used to store data for multiple threads and allow the datafor each thread to be accessed independently.

Accordingly, there is a desire to use a FIFO memory generator to producesynthesizable code for a shared FIFO to store data for multiple threads.

SUMMARY OF THE INVENTION

The current invention involves new systems and methods for generatingsynthesizable code representing FIFO memories to store data formulti-threaded processing. A single FIFO memory that can simultaneouslystore data for multiple threads is produced by synthesizing thegenerated code. A synthesizable code generator produces synthesizablecode for a sender interface, storage, receiver interface, and otherfeatures that are specified by a programmer. The other features mayreduce power consumption or improve timing. The code generator is usedto efficiently produce different variations of FIFO memories.Specifically, the sender interface may include a speculative writecapability and the receiver interface may include a speculative readcapability.

Various embodiments of a method of the invention for storing data formultiple execution threads in a FIFO (first-in first-out memory) storageinclude issuing a sender credit to a sender indicating that at least oneentry is available in the FIFO storage to store the data, receiving datafor a first thread of the multiple execution threads from the sender,and obtaining a pointer to an entry in the FIFO storage from a freepointer list that includes pointers to entries in the FIFO storage thatare available to store data for the multiple execution threads. The datais stored in the entry and the pointer is stored in an ordered list ofpointers corresponding to the first thread. A rollback address, a baseaddress, and a reject address are each incremented for a second threadthat is above the first thread in the ordered list of pointers.

Various embodiments of a system of the invention for storing data formultiple execution threads include a sender interface, a FIFO (first-infirst-out memory) storage, a receiver interface, an ordered pointerlist, a thread base address list, and a thread rollback address. Thesender interface is configured to receive the data for the multipleexecution threads from a sender. The FIFO storage is coupled to thereceiver interface and configured to store the data for the multipleexecution threads. The receiver interface is coupled to the FIFO storageand configured to output data from the FIFO storage to a receiver. Theordered pointer list is coupled to the FIFO storage and configured tostore free pointers corresponding to entries in the FIFO storage thatare available to store data in a first portion storing and to storepointers corresponding to entries in the FIFO storage that store datafor the multiple execution threads in a second portion. The thread baseaddress list is configured to store a base address indicating an entryin the ordered pointer list that stores a next entry to read for eachone of the multiple execution threads. The thread rollback address listis configured to store a rollback address indicating an oldest entry inthe ordered pointer list that has not been committed by the receiver foreach one of the multiple execution threads.

BRIEF DESCRIPTION OF THE DRAWINGS

So that the manner in which the above recited features of the presentinvention can be understood in detail, a more particular description ofthe invention, briefly summarized above, may be had by reference toembodiments, some of which are illustrated in the appended drawings. Itis to be noted, however, that the appended drawings illustrate onlytypical embodiments of this invention and are therefore not to beconsidered limiting of its scope, for the invention may admit to otherequally effective embodiments.

FIG. 1A illustrates a block diagram of a computing system including asynthesizable code generator in accordance with one or more aspects ofthe present invention.

FIG. 1B illustrates the synthesizable code generator and synthesizedcode shown in FIG. 1A in accordance with one or more aspects of thepresent invention.

FIG. 1C illustrates a flow diagram of an exemplary method of generatingsynthesizable code for a FIFO memory in accordance with one or moreaspects of the present invention.

FIG. 1D illustrates a flow diagram of an exemplary method of performingstep 100 shown in FIG. 1C in accordance with one or more aspects of thepresent invention.

FIG. 1E illustrates a flow diagram of an exemplary method of performingstep 120 shown in FIG. 1C in accordance with one or more aspects of thepresent invention.

FIG. 1F illustrates a flow diagram of an exemplary method of performingstep 130 shown in FIG. 1C in accordance with one or more aspects of thepresent invention.

FIG. 1G illustrates a flow diagram of an exemplary method of performingstep 150 shown in FIG. 1C in accordance with one or more aspects of thepresent invention.

FIG. 1H illustrates a block diagram of a synthesized FIFO memory inaccordance with one or more aspects of the present invention.

FIG. 2A illustrates a block diagram of a multi-threaded FIFO memory inaccordance with one or more aspects of the present invention.

FIG. 2B illustrates a conceptual diagram of data entries in amulti-threaded FIFO memory in accordance with one or more aspects of thepresent invention.

FIG. 3A illustrates a flow diagram of an exemplary method of trackingthe status of entries in the multi-threaded FIFO memory of FIG. 2A inaccordance with one or more aspects of the present invention.

FIG. 3B illustrates a flow diagram of an exemplary method of providingdata for storage in the multi-threaded FIFO memory of FIG. 2A inaccordance with one or more aspects of the present invention.

FIG. 3C illustrates a flow diagram of an exemplary method of trackingthe status of entries in the multi-threaded FIFO memory of FIG. 2A thatincludes speculative read and write capability in accordance with one ormore aspects of the present invention.

FIG. 4A illustrates a flow diagram of an exemplary method of performingthe functions of the receiver interface of FIG. 2A in accordance withone or more aspects of the present invention.

FIG. 4B illustrates a flow diagram of an exemplary method of obtainingdata from the multi-threaded FIFO memory of FIG. 2A in accordance withone or more aspects of the present invention.

FIG. 5A illustrates a conceptual diagram of a thread pointer list andthe FIFO storage in accordance with one or more aspects of the presentinvention.

FIG. 5B illustrates a conceptual diagram of a base address storage, areject address storage, a rollback address storage, and an orderedpointer list that includes a free entry pointer list and several threadpointer lists in accordance with one or more aspects of the presentinvention.

FIG. 5C illustrates another conceptual diagram of the ordered pointerlist in accordance with one or more aspects of the present invention.

FIG. 6A illustrates a flow diagram of an exemplary method of performingstep 350 shown in FIG. 3A in accordance with one or more aspects of thepresent invention.

FIG. 6B illustrates a flow diagram of an exemplary method of performingstep 352 shown in FIG. 3C in accordance with one or more aspects of thepresent invention.

FIG. 6C illustrates a flow diagram of an exemplary method of performingstep 415 shown in FIG. 4A in accordance with one or more aspects of thepresent invention.

FIG. 6D illustrates a flow diagram of an exemplary method of performingstep 420 shown in FIG. 4A in accordance with one or more aspects of thepresent invention.

DETAILED DESCRIPTION

In the following description, numerous specific details are set forth toprovide a more thorough understanding of the present invention. However,it will be apparent to one of skill in the art that the presentinvention may be practiced without one or more of these specificdetails. In other instances, well-known features have not been describedin order to avoid obscuring the present invention.

The current invention involves new systems and methods for efficientlyproducing different variations of FIFO memories. In particular, asynthesizable code generator may be used to produce FIFO memories formulti-threaded processing. A single FIFO memory is shared between thethreads to conserve die area. However, each thread may be executedindependently, as if each thread has a dedicated FIFO memory. Asynthesizable code generator produces synthesizable code for a senderinterface, storage, receiver interface, and other features that arespecified by a programmer. The sender interface may include aspeculative write capability to allow write data to be stored in theFIFO memory and discarded before it is accessed by the receiverinterface. The receiver interface may include a speculative readcapability to allow read data to remain in the FIFO memory after it isread and removed from the FIFO memory at a later time.

FIG. 1A illustrates a block diagram of a computing system including acentral processing unit (CPU) 101 and a system memory 105, in accordancewith one or more aspects of the present invention. A generator program,generator 103 is stored in memory 105. When executed by CPU 101,generator 103 produces synthesizable code 107 representing a FIFOmemory. Synthesizable code 107 may be combined with other code, producedby a generator program or authored by a programmer, to producesynthesizable code for an integrated circuit. Synthesizable code 107 maybe written in Verilog, VHDL, or other hardware description languagesknown to those skilled in the art. Synthesizable code 107 may besynthesized using a commercially available synthesis tools such asDesign Compiler® produced by Synopsys and Synplify® produced bySynplicity, to produce a netlist defining the components and connectionsof the integrated circuit.

FIG. 1B illustrates synthesizable code generator 103 and synthesizedcode 107 of FIG. 1A, in accordance with one or more aspects of thepresent invention. Generator 103 includes components (generators) thatare used to produce corresponding components of synthesizable code 107.In particular, a first portion of generator 103, sender interface codegenerator 109 produces synthesizable sender interface code 111 whenexecuted by CPU 101. A second portion of generator 103, receiverinterface code generator 113 produces synthesizable receiver interfacecode 115 when executed by CPU 101. A third portion of generator 103,storage code generator 116 produces synthesizable storage code 117 whenexecuted by CPU 101. A fourth portion of generator 103, optionalfeatures code generator 118 produces synthesizable optional featurescode 119 when executed by CPU 101.

Storage code 117 is used to synthesize (or instantiate) the storageresources within the FIFO memory, e.g., flip flops, registers, latches,random access memory (RAM), or the like. Sender interface code 111 isused to synthesize the input interface that receives data for storage inthe FIFO memory. Receiver interface code 115 is used to synthesize theoutput interface that outputs data that is stored in the FIFO memory.Optional features code 119 is used to synthesize logic for amulti-threaded FIFO memory that permits storage and access of data formultiple execution threads in a single storage resource. Optionalfeatures code 119 may also be used to synthesize logic to reduce powerconsumption, improve interface timing, include asynchronous interfaces,or the like. For example, flip flops may be used to receive or outputdata to improve interface timing. Clock gating may be added to reducepower consumption for portions of the FIFO memory that are idle orstatic.

FIG. 1C illustrates a flow diagram of an exemplary method of generatingsynthesizable code for a FIFO memory in accordance with one or moreaspects of the present invention. In step 100 sender interface codegenerator 109 is executed to produce sender interface code 111. In step120 storage code generator 116 is executed to produce storage code 117.In step 130 receiver interface code generator 113 is executed to producereceiver interface code 115. In step 150 optional features codegenerator 118 is executed to produce optional features code 119. Steps100, 120, 130, and 150 are described in further detail in conjunctionwith FIGS. 1D, 1E, 1F, and 1G, respectively.

FIG. 1D illustrates a flow diagram of an exemplary method of performingstep 100 shown in FIG. 1C in accordance with one or more aspects of thepresent invention. In step 102 the inputs provided to generator 103 areexamined to determine if a credit based sender interface is specified.The inputs may be received from a user via a command line interface ormay be generated by another generator that produces a higher level ofthe hierarchy of the integrated circuit. If, in step 102 generator 103determines that a credit based interface is specified, then in step 104sender interface code generator 109 is executed to produce senderinterface code 111 including a credit based interface. The functionsperformed by a credit based sender interface are described in moredetail in conjunction with FIG. 3A.

In step 106, generator 103 determines if the reset credit option isspecified for the sender credit based interface, and, if so, in step 108sender interface code generator 109 is executed to produce senderinterface code 111 including immediate credit logic. The immediatecredit logic outputs one or more sender credits to the senderimmediately after coming out of reset. If, in step 106 generator 103determines that the reset credit option is not specified for the sendercredit based interface, then generator 103 proceeds to step 124.

If, in step 102 generator 103 determines that a credit based interfaceis not specified, then in step 110 sender interface code generator 109is executed to produce sender interface code 111 including arequest/busy interface. In one embodiment of the present invention, abusy signal is output by the sender interface and the sender interfaceaccepts requests only when busy is negated, i.e., when busy is assertedrequests are ignored. In other embodiments of the present invention,other sender interface types may be defined and specified.

In step 124 generator 103 determines if a speculative write capabilityis specified, and, if so, in step 127 a commit port and a reject port isadded. The commit port is used to postpone writing to the storageresource until the commit signal is asserted. The reject port is used toreject all writes received that have not been committed using the commitport. A reject pointer is maintained that is updated whenever a write iscommitted. The speculative write option is useful for packet processingapplications since incoming packets may be stored and later rejected,such as when a packet fails an error checking test. If, in step 124generator 103 determines that a speculative write capability is notspecified, then generator 103 proceeds directly to step 112.

In step 112 generator 103 determines if one or more port options arespecified, and, if so, in step 114 sender interface code generator 109is executed to produce sender interface code 111 including theadditional ports. For example, an idle port (for all or each thread) maybe included in the sender interface to indicate when the senderinterface is idle. An empty port may also be included in the senderinterface to indicate that the storage resource is empty. A write countport (for all or each thread) may also be included in the sender toindicate the number of entries in the storage resource that are used.The storage resource write address, read address, pop, push, and thelike may also be output via ports of the sender interface. Theseadditional ports may be used during functional verification or may beused by the sender to perform performance optimizations.

In other embodiments of the present invention, other options may bespecified for inclusion in the sender interface. For example, a limitvalue may be defined to artificially limit the number of entries thatmay be used, i.e., credits issued, in the FIFO memory. A partial writeoption may be specified to enable writes of one or more portions of anentry and write enable ports are included in the sender interfacecorresponding to the one or more portions. The polarity of the busysignal may be reversed when a request/busy sender interface isspecified. Another option may be used to specify that the busy signal ofa request/busy sender interface is associated with the next clock cycleinstead of the current clock cycle. Sender interface code generator 109may be configured to produce sender interface code 111 based on avariety of options specified by inputs to generator 103. Therefore,generator 103 may be used to efficiently produce FIFO memories with manydifferent features.

FIG. 1E illustrates a flow diagram of an exemplary method of performingstep 120 shown in FIG. 1C in accordance with one or more aspects of thepresent invention. In step 121 the inputs provided to generator 103 areexamined to determine if a flip flop based storage resource isspecified, and, if so, in step 122 storage code generator 116 isexecuted to produce storage code 117 to specify flip flops as thestorage devices. If, in step 122 the inputs provided to generator 103 donot specify using flip flop based storage devices, then in step 123storage code generator 116 is executed to produce storage code 117 toselect the storage device, e.g., flip flop, RAM, latches, or the like,based on criterion provided to storage code 117, e.g., minimal die area,maximum speed, or the like.

In step 125 generator 103 determines if bypass option is specified forthe storage resource, and, if not, generator 103 proceeds to step 130.Otherwise, in step 126, storage code generator 116 is executed toproduce storage code 117 including a bypass path to bypass the storagewhen the FIFO memory is empty. The bypass option may be used to reducelatency through the FIFO memory when the FIFO memory is empty. In otherembodiments of the present invention, additional options may bespecified. For example, multiple read and/or write ports may be includedin storage code 117.

FIG. 1F illustrates a flow diagram of an exemplary method of performingstep 130 shown in FIG. 1C in accordance with one or more aspects of thepresent invention. In step 132 the inputs provided to generator 103 areexamined to determine if a take based receiver interface is specified,and, if not, in step 110 receiver interface code generator 113 isexecuted to produce receiver interface code 115 including a request/busyinterface. In some embodiments of the present invention, a credit basedreceiver interface may be specified. A credit based receiver interfacereceives credits from the receiver and maintains a credit count for eachthread. The receiver interface outputs data from the FIFO memory for athread when a credit is available for the thread and updates the creditcount for the thread.

If, in step 132 generator 103 determines that a take based interface isspecified, then in step 134 receiver interface code generator 113 isexecuted to produce receiver interface code 115 including a take basedinterface. The functions performed by a take based receiver interfaceare described in more detail in conjunction with FIG. 4A. The basicfunction of a take based interface is that a take output signal ispulsed when a new entry is available in the FIFO memory. When the FIFOmemory is configured as a multi-threaded FIFO memory the take portincludes a bit for each thread.

In step 138, generator 103 determines if the take partial option isspecified for the receiver take based interface, and, if so, in step 140receiver interface code generator 113 is executed to produce receiverinterface code 115 including peek logic. The peek logic allows areceiver to read data from the FIFO memory without popping (removing)the data from the FIFO memory. In some embodiments of the presentinvention, data is popped when the take signal is asserted and peekedwhen the take partial signal is asserted and the take signal is negated.The functions performed by the take partial feature in a take basedreceiver interface are described in more detail in conjunction with FIG.4C. If, in step 138 generator 103 determines that the take partialoption is not specified for the take based receiver interface, thengenerator 103 proceeds directly to step 142.

In step 142, generator 103 determines if the take offset option isspecified for the receiver take based interface, and, if so, in step 144receiver interface code generator 113 is executed to produce receiverinterface code 115 including read offset logic. The read offset logicallows a receiver to read data from any location of the FIFO memory.Data is read (peeked or popped) from the FIFO base+offset entry. Thefunctions performed by the take offset feature in a receiver interfaceare described in more detail in conjunction with FIGS. 5C, 6C, and 6D.If, in step 142 generator 103 determines that the take offset option isnot specified for the take based receiver interface, then generator 103proceeds directly to step 137.

In step 137 generator 103 determines if a speculative read capability isspecified, and, if so, in step 145 a commit port, a rollback port androllback logic is added. The commit port is used to postpone removingdata that is read from the storage resource until the commit signal isasserted. The rollback port is used to restore the read pointer to pointto the first data that has not been removed as a result of a commitsignal. A rollback pointer to an entry in the FIFO memory is incrementedwhen the commit signal is asserted and the current read pointer is setto the rollback pointer when the rollback signal is asserted. When thespeculative read capability is specified for the receiver interface, thetake port may be configured to read data without removing it from theFIFO memory. The speculative read option is useful for reducing the sizeof buffers needed to receive data that is popped from the FIFO memorysince data is read, but not popped until later, using the commit port.If, in step 124 generator 103 determines that a speculative readcapability is not specified, then generator 103 proceeds directly tostep 146.

In step 146 generator 103 determines if one or more port options arespecified, and, if so, in step 148 receiver interface code generator 113is executed to produce receiver interface code 115 including additionalports or removing ports. For example, the credit port(s) may be omittedfrom the receiver interface. When several FIFO memories are used inparallel, only a credit port from one of the FIFO memories may be usedfor the receivers. Similarly, the busy input signal may be omitted forthe request/busy interface. A read count port (for all or each thread)may also be included in the receiver interface to indicate the number ofentries in the storage resource that are used. A free count port (forall or each thread) may also be included in the receiver interface toindicate the number of entries in the storage resource that areavailable for storage. The storage resource read address, pop, enable,and the like may also be output via ports of the receiver interface.

In other embodiments of the present invention, other options may bespecified for inclusion in the receiver interface. For example, a replayport may be specified as an input that causes data to be read from theFIFO memory using a secondary pointer. An ignore read credits option maybe specified to cause the receiver interface to output data whenever itis available, regardless of the number of input read credits a receiverhas provided to the receiver interface. Another option may be used tospecify that the busy input signal of a request/busy receiver interfaceis associated with the next clock cycle instead of the current clockcycle. Like sender interface code generator 109, receiver interface codegenerator 113 may be configured to produce receiver interface code 115based on a variety of options specified by inputs to generator 103.Therefore, generator 103 may be used to efficiently produce FIFOmemories with many different features.

FIG. 1G illustrates a flow diagram of an exemplary method of performingstep 150 shown in FIG. 1C in accordance with one or more aspects of thepresent invention. In step 152 generator 103 determines if anasynchronous boundary option is specified for the FIFO memory, and, ifnot, generator 103 proceeds to step 156. Otherwise, in step 154,optional features code generator 118 is executed to produce optionalfeatures code 119 including asynchronous boundary interfaces to transfersignals between two different clock domains (the sender clock domain andthe receiver clock domain).

In step 156 generator 103 determines if a multi-threaded option isspecified for the FIFO memory, and, if not, generator 103 proceeds tostep 162. Otherwise, in step 156 optional features code generator 118 isexecuted to produce optional features code 119 including multi-threadedlogic. In particular, an ordered pointer list is included which storespointers to the entries in the storage resource and is used to maintainper-thread linked lists to emulate per-thread FIFOs. The multithreadedlogic is described in greater detail in conjunction with FIG. 5B.

In step 162 generator 103 determines if a lower power option isspecified for the FIFO memory, and, if not, generator 103 proceeds tostep 166. Otherwise, in step 164 optional features code generator 118 isexecuted to produce optional features code 119 including adding clockgating. In particular fine grained clock gating may be inserted for datainput to the receiver interface. In step 166 generator 103 determines ifa better timing option is specified for the FIFO memory, and, if not,generator 103 proceeds to step 166. Otherwise, in step 164 optionalfeatures code generator 118 is executed to produce optional featurescode 119 including inserting registers on input and output signals andto duplicate signals with multiple loads. In other embodiments of thepresent invention, additional options may be defined. After completingstep 166 and/or 168, synthesizable optional features code 119 is outputand synthesizable code 107 is complete.

FIG. 1H illustrates a block diagram of a synthesized FIFO memory 170that may be produced using generated synthesizable code 107, inaccordance with one or more aspects of the present invention. A senderinterface 184 includes a request/busy interface with a request signal,wr_req 172 and a busy signal, wr_busy 173. The sender data is providedby wr_data 171. Sender interface 184 outputs write control signals to astorage unit 185 and a receiver interface 187 outputs read controlsignals to storage unit 185. A boundary unit 186 may be used to transfersignals between a sender clock domain and a receiver clock domain. Theasynchronous option may be specified to cause generator 103 to producesynthesizable code for boundary unit 186. Receiver interface includes arequest/busy interface with a request signal, rd_req 192 and a busysignal, rd_busy 193. The receiver data is provided by rd_data 191.Registers 181, 182, and 183 may be synthesized to register the inputs toimprove timing by using the better timing option for generator 103.Likewise, registers 196, 197, and 198 may be synthesized to register theoutputs to improve timing.

The following command line may be used to produce synthesized FIFOmemory 170:

-   -   FIFOGEN -m my_fifo -d my_fifo_depth -w my_fifo_width -ram ra2        -async -wr_reg -rd_reg

My_fifo specifies the module name for synthesized FIFO memory 170.My_fifo_depth specifies the depth of storage unit 185 and my_fifo_widthspecifies the width of storage unit 185. Ra2 specifies that storage unit185 the storage device, e.g., flip flop, RAM, latches, or the like,selected during synthesis is based on criterion provided to storage code117, e.g., minimal die area, maximum speed, or the like. The -asyncinput specifies that generator 103 should produce synthesizable code forboundary unit 186. The -wr_reg input specifies that generator 103 shouldproduce synthesizable code for registers on one or more of the writeinterface ports, e.g., registers 181, 182, and 183. The -rd_reg inputspecifies that generator 103 should produce synthesizable code forregisters on one or more of the read interface ports, e.g., registers196, 197, and 198. A -wr_spec input may be used to specify thatgenerator 103 should produce synthesizable code for a speculative writecapability as part of sender interface 184. A -rd_rollback input may beused to specify that generator 103 should produce synthesizable code fora speculative read capability as part of receiver interface 187.

Generator 103 may be used to produce synthesizable code for amulti-threaded FIFO memory. Instead of using a separate FIFO memory tostore data for each thread, a single FIFO memory is produced to storedata for multiple threads. The FIFO memory is shared between the threadsto conserve die area, however each thread may be executed independently,as if each thread has a dedicated FIFO memory. A multi-threaded FIFOmemory including the single FIFO memory may be used to perform real-timeprocessing for one or more threads, but specifying those threads ashaving a higher priority for accessing the multi-threaded FIFO. Themulti-threaded FIFO memory may also be used to sort out of order data.For example, each DRAM (dynamic random access memory) page may beassigned a different thread identifier and the data for each page may bepopped from the single FIFO memory to reduce any latency incurredaccessing the DRAM. In other circumstances the multi-threaded FIFOmemory may be used to avoid deadlock conditions in a processingpipeline.

FIG. 2A illustrates a block diagram of a multi-threaded FIFO memory 200,in accordance with one or more aspects of the present invention.Multi-threaded FIFO memory 200 includes a sender interface 210, a readand write control 225, a FIFO storage 220, and a receiver interface 230.FIFO storage 220 may include flip flops, random access memory, or thelike. Sender interface 210 issues sender credits via sender credits 215and receives thread data from a sender via sender data 205 for storagein FIFO storage 220. Sender data may be received and stored for eachsender credit that has been issued via sender credits 215. Sendercredits 215 include a bit for each dedicated class and for the sharedclass. A dedicated class is allocated a number of entries in FIFOstorage 220 that may only be used to store data for threads included inthe dedicated class. A shared class is allocated a number of entriesthat may be used to store data for any thread. All threads areimplicitly in the shared class.

The number of entries allocated to each class is specified by classlimits 203. Class limits 203 may be changed for one or more classeswhile data is stored in FIFO storage 220. Programmable limits for eachclass may be specified using program instructions at the applicationlevel. Default limit values may be provided or values may be determinedand programmed by a device driver during multi-threaded processing. Inother embodiments of the present invention, the limit values may behardwired. The combination of the number of credits issued for a classand the number of entries storing thread data included in the classshould not exceed the credit limit defined for the class.

In addition to sender data 205, a sender also provides a shared classdebit flag via sender debit shared 201, a threadID via sender threadID204 and a valid signal via sender valid 202. The sender indicates that ashared class credit is used for sender data by asserting debit shared201. When a dedicated class credit is used for sender data, debit shared201 is negated. Each thread has a unique thread identifier, threadID.Threads are assigned to classes, with each class including one or morethreads. The valid signal is asserted by the sender when sender data isprovided for storage. For each clock cycle that a bit of sender credits215 is asserted, the valid signal may be asserted to provide data and“use” a sender credit. Issuing sender credits ensures that the senderdoes not provide more data than can be stored in FIFO storage 220.Therefore, sender interface 210 must accept the data provided by thesender when the valid signal is asserted.

This protocol is particularly well-suited to transfer data between asender and a multi-threaded FIFO memory 200 that are not adjacent on adie and may have one or more retiming flip-flops inserted between theirconnections to meet timing constraints, such as long haul signals. Inother embodiments of the present invention, sender credits 215 may bereplaced with a signal indicating whether or not data may be acceptedduring the current clock cycle.

Sender interface 210 outputs data for storage in FIFO storage 220 andoutputs the threadID corresponding to the data and a push signal to readand write control 225. The push signal is asserted whenever sendercommit 207 is asserted in order to advance the reject pointer. A baseaddress that points to the next entry in FIFO storage 220 that isavailable for writing is updated whenever sender valid 202 is asserted.Sender interface 210 determines the number of sender credits output foreach class based on the limit values, as described in conjunction withFIG. 3A.

Sender interface 210 receives a pop signal and threadID from read andwrite control 225 when data corresponding to the threadID is popped fromFIFO storage 220, i.e., when receiver commit 247 is asserted. A rolloverpointer is advanced whenever receiver commit 247 is asserted. A baseaddress that points to the oldest entry in FIFO storage 220 for readingis updated whenever receiver take 244 is asserted. Read and writecontrol 225 generates read and write requests, including addresses(pointers to entries in FIFO storage 220), for output to FIFO storage220, as described in conjunction with FIGS. 6A, 6B, 6C, and 6D. When thereject and rollback features are used, the addresses include baseaddresses for writing the next available entry and reading the oldestentry, as well as a rollback pointer and a reject pointer.

Read and write control 225 outputs the threadID corresponding to thedata provided to FIFO storage 220 by sender interface 210 and a pushsignal to receiver interface 230. Receiver interface 230 uses thethreadID and push signal to generate receiver credits 224. For eachassertion of the push signal, a bit of receiver credit corresponding tothe threadID is asserted, indicating that data for the threadID isavailable in FIFO storage 220 and may be read and/or popped. When a takerequest is presented via receiver take 244, data for the threadcorresponding to receiver threadID 231 is output to receiver data 235.Note that data is not removed from FIFO storage 220 when receiver take244 is asserted, unless the rollback capability is not available inmulti-threaded FIFO memory 200. When the rollback capability isavailable in multi-threaded FIFO memory 200, receiver take 244 does notremove the data from FIFO storage 220. In order to remove the data fromFIFO storage 220 receiver commit 246 must also be asserted eithersimultaneously with receiver take 244 or at a later time. Receiverinterface 230 outputs a pop signal (corresponding to the take or commitrequest), receiver rollback 248, receiver threadID 231, receiver offset232, and a receiver peek 245 signal to read and write control 225.

A peek request is presented via receiver peek 245 and is used to readdata from FIFO storage 220 without removing (popping) the data from FIFOstorage 220. After data is read by for a peek request, the data may bepopped (read and removed from FIFO storage 220) by a take request (whenthe rollback capability is not available) or by a receiver commitrequest. Receiver offset 232 is used to read data stored in an entry ofa FIFO for a thread that is offset from the head of the FIFO. Ratherthan reading data at the top of the FIFO, i.e., the oldest data in theFIFO, data from other positions in the FIFO may be read by specifying anon-zero offset for receiver offset 232. Receiver offset 232 isindependent of receiver rollback 248 and receiver commit 247. Therefore,entries in FIFO storage 220 are freed in FIFO order by receiver commit247. Receiver rollback 248 is used to set the base address that pointsto the oldest data to the rollback pointer in order to output one ormore entries again using receiver take 244.

Multi-threaded FIFO memory 200 also receives a reset signal and at leastone clock signal. In some embodiments of the present invention,multi-threaded FIFO memory 200 is asynchronous and a first clock isprovided by a sender to sender interface 210 and a second clock isprovided by a receiver to receiver interface 230. When multiplereceivers read data stored in multi-threaded FIFO memory 200, an arbitermay be coupled between the multiple receivers and multi-threaded FIFOmemory 200. Likewise, when multiple senders provide data tomulti-threaded FIFO memory 200, an arbiter may be coupled between themultiple senders and multi-threaded FIFO memory 200.

The following command line may be used to produce synthesizedmulti-threaded FIFO memory 200:

-   -   FIFOGEN -m my_fifo -d my_fifo_depth -w my_fifo_width -ram ra2        -threads N -wr_credit -wr_immediate_credits -rd_take        -rd_take_offset -rd_take partial -rd_rollback -wr_spec

My_fifo specifies the module name for synthesized multi-threaded FIFOmemory 200. My_fifo_depth specifies the depth of FIFO storage 220 andmy_fifo_width specifies the width of FIFO storage 220. Ra2 specifiesthat the storage device, e.g., flip flop, RAM, latches, or the like,selected during synthesis is based on criterion provided to FIFO storage220, e.g., minimal die area, maximum speed, or the like. The -threadsinput specifies that generator 103 should produce synthesizable code forN execution threads. The -wr_credit input specifies that generator 103should include synthesizable code for a credit based interface in senderinterface 210. The -wr_immediate_credits input specifies that generator103 should include synthesizable code for immediate sender credits(following a reset) to be issued by sender interface 210.

The -rd_take input specifies that generator 103 should includesynthesizable code for a take based interface in receiver interface 230.The -rd_take_offset and -rd_take partial inputs specify that generator103 should include synthesizable code for the offset and peek requestfeatures, respectively, in receiver interface 230. The -wr_spec inputspecifies that generator 103 should include synthesizable code for aspeculative write capability as part of sender interface 184 and rejectpointer logic as part of read and write control 225. The -rd_rollbackinput specifies that generator 103 should include synthesizable code fora speculative read capability as part of receiver interface 187 rollbackpointer logic as part of read and write control 225.

FIG. 2B illustrates a conceptual diagram of data entries, FIFO entries250, in FIFO storage 220 of multi-threaded FIFO memory 200, inaccordance with one or more aspects of the present invention. In orderto store data in each entry of FIFO storage 220, the number of entriesallocated to the combination of the dedicated classes and shared class,i.e., the number of entries in FIFO entries 250, should be equal to thenumber of entries in FIFO storage 220. A limit value may be specifiedfor each of class 1 entries 251, class 2 entries 252, class n entries253, and shared entries 254. The sum of the limit values should notexceed the number of entries in FIFO storage 220.

As previously described, each class may include one or more threads,specified by their respective threadIDs. For example, class 1 entries251 may be configured to store data for threadID 1 and threadID 2. Class2 entries 252 may be configured to store data for threadID 3. Sharedentries 252 may be configured to store data for threadID 4. Becauseshared entries 252 is a shared class, shared entries 252 may also storedata for threadID 1, threadID 2, and threadID 3.

FIG. 3A illustrates a flow diagram of an exemplary method of trackingthe status of entries in FIFO storage 220, in accordance with one ormore aspects of the present invention. In step 300 multi-threaded FIFOmemory 200 receives a reset signal. In step 305 sender interface 210initializes sender credits by issuing a predetermined number of creditsfor each class via sender credits 215. In one embodiment of the presentinvention, sender interface 210 issues one credit for each class.Therefore, a sender may begin providing data to multi-threaded FIFOmemory 200 following reset and without waiting to receive a credit. Thismay improve the data processing throughput of a system includingmulti-threaded FIFO memory 200.

Sender interface 210 maintains a count of issued credits for each class,referred to as issued dedicated credit counts and an issued sharedcredit count. The issued credit counts are updated to indicate thenumber of credits issued for each class in step 305. In some embodimentsof the present invention, sender interface 210 may also maintain a countof credits for which data is stored in FIFO storage 220, referred to asoccupied dedicated credit counts and occupied shared credit count.

In those embodiments, a total dedicated credit count can be computed fora dedicated class by summing the occupied dedicated credit count andissued dedicated credit count for the dedicated class. Similarly, atotal shared credit count can be computed for the shared class bysumming the occupied shared credit count and issued shared credit countfor the shared class. The total dedicated credit count for a dedicatedclass should not exceed the limit value for the dedicated class.Likewise, the total shared credit count for the shared class should notexceed the limit value for the shared class. In other embodiments of thepresent invention, the issued dedicated credit counts and issued sharedcredit count include the issued credits and the occupied credits and theissued credit counts are equal to the total credit counts.

In step 305 sender interface 210 may also receive limit values for eachclass via class limits 203 and store the limit values in registers. Thelimit values define the maximum number of dedicated credits availablefor each dedicated class and the maximum number of shared creditsavailable for the shared class.

In step 310 sender interface 210 determines if the number of dedicatedcredits issued for any class is less than the maximum number ofdedicated credits, i.e., dedicated limit, for the class. If, in step 310sender interface 210 determines that one or more classes have dedicatedcredits that may be issued, in step 315 sender interface 210 incrementsthe issued dedicated credit count for each of the one or more classes.Each issued dedicated credit count may be incremented by one or moredepending on the number of sender credits that will be issued to theclass. In some embodiments of the present invention, each issueddedicated credit count is incremented once per clock cycle. In otherembodiments of the present invention, multiple credits may be issued ina single clock cycle and each issued dedicated credit count may beupdated accordingly in a single clock cycle. In step 320 senderinterface 210 issues sender credits to each of the one or more classes.Sender interface 210 may issue one sender credit to each of the one ormore classes or sender interface 210 may issue more than one sendercredit to each of the one or more classes.

If, in step 310 sender interface 210 determines that all of the classeshave issued dedicated credit counts equal to their respective limitvalues, then in step 325 sender interface 210 determines if the numberof shared credits issued for any class (issued shared credit count) isless than the maximum number of shared credits. If, in step 325 senderinterface 210 determines that shared credits are available for issue,then in step 330 sender interface 210 increments the issued sharedcredit count for the shared credit class. The issued shared credit countmay be incremented by one or more depending on the number of sharedcredits that will be issued. In step 335 sender interface 210 issuesshared credits to the shared class. Sender interface 210 may issue oneshared credit or sender interface 210 may issue more than one sharedcredit.

In step 340 sender interface 210 determines if the sender valid signalis asserted, i.e., the sender is providing data to multi-threaded FIFOmemory for storage. If, in step 340 the sender valid signal is notasserted, then sender interface 210 proceeds directly to step 360. If,in step 340 the sender valid signal is asserted, then in step 350 senderinterface 210 asserts a push signal to read and write control 225 andoutputs sender data 205 to FIFO storage 220. Sender interface 210 alsooutputs the sender threadID and the shared class debit flag to read andwrite control 225. A more detailed description of step 350 is providedin conjunction with FIG. 6A.

In step 360 sender interface 210 determines if a pop signal is receivedfrom read and write control 225, and, if not, sender interface 210returns to step 310 to determine if more credits may be issued.Otherwise, in step 365 sender interface 210 decrements the issued creditcount corresponding to the data that was popped from FIFO storage 220.After completing step 365, sender interface 210 returns to step 310 todetermine if more credits may be issued. In other embodiments of thepresent invention, additional limit values, thresholds, and the like maybe used to control the output of sender credits to a sender.Furthermore, varying techniques of allocating the shared credits betweendifferent dedicated classes may be used by the sender. For example, apriority may be specified for each class and the allocation of sharedcredits may be influenced by the priority of each class. When senderreject 208 is asserted the sender restores the credits associated withentries that are removed from FIFO storage 220. Therefore, senderinterface 210 only outputs credits once and does not issue credits forrejected entries.

FIG. 3B illustrates a flow diagram of an exemplary method of providingdata for storage in FIFO storage 220, in accordance with one or moreaspects of the present invention. The method steps shown in FIG. 3B maybe performed by a sender providing data for storage in FIFO storage 220.In step 370 the sender determines that valid data is ready for output tomulti-threaded FIFO memory 200. In step 375, the sender determines if adedicated credit is available based on the class that includes thethreadID and class of the dedicated credit. The sender maintains a countof dedicated credits received from sender interface 210 for each class.As previously described, the sender maintains a count of the committedcredits for each class and the shared credits that have been committedin order to restore credits when the sender asserts sender reject 208.The sender also maintains a mapping of threadIDs to classes in order todetermine whether an available credit may be used to send data for aparticular threadID.

If, in step 375 the sender determines that a dedicated credit isavailable, then sender interface proceeds directly to step 381.Otherwise, in step 380 the sender determines if a shared credit isavailable, and, if not, the sender returns to step 375 and waits for adedicated or shared credit to be issued. In step 381, the senderdetermines if the valid data should be committed to FIFO storage 220.Committed data cannot be removed from FIFO storage 220 by the sender,whereas uncommitted data can be removed by the send using sender reject208. If, in step 381 the sender determines that the valid data shouldnot be committed, then the sender proceeds directly to step 385.

Otherwise, in step 382 the sender asserts send commit 208 for the validdata. In step 383 the sender decrements a committed credit count andproceeds to step 385. The credit may be a dedicated or shared classcredit and the sender may maintain information to restore the dedicatedand shared class credits separately when the reject capability is used.

In step 385 the sender outputs data to multi-threaded FIFO memory 200via sender data 205, for storage in FIFO storage 220. The sender alsooutputs the shared class debit flag, the sender valid signal, and thesender threadID, to sender interface 210. In step 390 the senderdecrements the credit count, shared or dedicated, corresponding to theclass that was output in step 385. In some embodiments of the presentinvention, the sender may use shared credits before using dedicatedcredits. In other embodiments of the present invention, the sender mayrely on threadID or class priorities in determining whether to use ashared or dedicated credit to output data for a thread. In still otherembodiments of the present invention, the sender may accumulate severalsender credits and send data for a particular threadID over severalconsecutive cycles, i.e., a burst.

FIG. 3C illustrates a flow diagram of an exemplary method of trackingthe status of entries in a multi-threaded FIFO memory 220 of FIG. 2Athat includes speculative read and write capability, in accordance withone or more aspects of the present invention. The method includes steps300, 305, 310, 315, 320, 325, 330, and 335 of FIG. 3A. Those steps arecompleted as previously described. In step 337 sender interface 210determines if sender reject 208 is asserted, and, if not, senderinterface 210 proceeds directly to step 340. Otherwise, in step 339sender interface 210 discards the uncommitted data for the thread IDspecified by sender threadID 204, and proceeds to step 340. Theuncommitted data for the thread ID is discarded by setting the writepointer to the reject pointer.

In step 340 sender interface 210 determines if the sender valid signalis asserted, and, if it is not, then sender interface 210 proceedsdirectly to step 360. If, in step 340 the sender valid signal isasserted, then in step 350 sender interface 210 asserts a push signal toread and write control 225 and outputs sender data 205 to FIFO storage220. In step 345 sender interface 210 determines if sender commit 207 isasserted, and, if not, sender interface 210 proceeds directly to step360. Otherwise, in step 352 sender interface 210 outputs sender commit207 to read and write control 225 and generates a push output to readand write control 225 before proceeding to step 360. Read and writecontrol 225 increments the reject pointer. The push is then output toreceiver interface 230 in order to update the available credits for thethread ID specified by sender threadID 204. Steps 360 and 365 arecompleted as described in conjunction with FIG. 3A.

FIG. 4A illustrates a flow diagram of an exemplary method of performingthe functions of the receiver interface 230 of FIG. 2A whenmulti-threaded FIFO memory 200 is configured for speculative readcapability, in accordance with one or more aspects of the presentinvention. In step 402 receiver interface 230 receives an input, i.e.,one or more of the following is asserted, receiver take 244, receiverpeek 245, receiver commit 247, receiver rollback 248. In step 402receiver interface 230 determines if a push is received from read andwrite control 225, and, if not, receiver interface 230 proceeds directlyto step 410. If, in step 400 receiver interface 230 determines that apush is received, then in step 405 receiver interface 230 outputs areceiver credit for the threadID. In addition to a push signal, receiverinterface 230 receives a threadID from read and write control 225.Unlike sender interface 210, receiver interface 230 issues credits forthreadIDs rather than classes. Therefore, receiver interface 230 doesnot rely on the class to threadID mapping.

In step 410 receiver interface 230 determines if a peek or take requestis received from a receiver, and, if not, receiver interface 230proceeds directly to step 417. A take request is received when receivertake 244 is asserted and a peek request is received when receiver peek245 is asserted. The take request indicates that the receiver wants datathat corresponds to the receiver threadID provided via receiver threadID231 to be output via receiver data 235. The peek request indicates thatthe receiver wants data from an entry specified by receiver offset 232that corresponds to the receiver threadID provided via receiver threadID231 to be output via receiver data 235. When data is output using a takeor peek request, the data is retained in FIFO storage 220, i.e., therollback pointer is not incremented. If, in step 410 receiver interface230 determines that a peek or take request is received, then in step 415receiver interface 230 reads data for the thread corresponding to thethreadID and outputs the data. A more detailed description of step 415is provided in conjunction with FIG. 6C.

When an offset specified via receiver offset 232 is zero, the data isread from FIFO storage 220 in FIFO order using the read pointer, i.e.,the data that was written first is read first for each thread. When theoffset is not zero, the data is read from FIFO storage 220 based on theoffset. The offset corresponds to the entry in the FIFO for a thread,where an offset of zero indicates the head of the FIFO (first-in entry)and an offset of n, where n is the size of the FIFO indicates the tailof the FIFO (last-in entry).

In step 417 receiver interface 230 determines if a peek request isreceived from a receiver or if a push is received from read and writecontrol 225, and, if so, receiver interface 230 proceeds directly tostep 425. If a peek request or push was not received, then the inputreceived in step 400 may be a take or rollback request, in which casereceiver interface 230 proceeds to step 420 to update the read and/orrollback pointers, as described in conjunction with FIG. 6D. In step 425the input processing is complete.

FIG. 4B illustrates a flow diagram of an exemplary method of obtainingdata from multi-threaded FIFO memory 200 of FIG. 2A, in accordance withone or more aspects of the present invention. In step 430 a receiverreceives one or more receiver credits from receiver interface 230 viareceiver credits 234. Receiver interface 230 asserts a bit of receivercredits 234 that corresponds to a particular threadID to issue areceiver credit for that particular threadID. The receiver maintains acount of available receiver credits for each threadID, accounting forreceiver credits that are restored when a rollback is requested. In step435 the receiver increments an available receiver credit countcorresponding to the threadID indicated by receiver credits 234. In someembodiments of the present invention, more than one receiver credit maybe issued in a cycle and one or more available receiver credit countsare updated accordingly in step 435.

In step 440 the receiver determines if data may be accepted frommulti-threaded FIFO memory 200 for any thread with an available receivercredit count greater than zero. If, in step 440 the receiver determinesthat data should be read for any thread using a take request, then instep 445 the receiver outputs a take request to multi-threaded FIFOmemory 200 and outputs the threadID for the thread via receiver threadID231 and the receiver proceeds to step 446. The receiver may also providean offset indicating that an entry other than the head of a thread FIFOshould be read.

If, in step 440 the receiver determines that data should not be read fora thread using a take request, then in step 442, the receiver determinesif data should be read (peeked) from multi-threaded FIFO memory 200 forany thread with an available receiver credit count greater than zero.If, in step 442 the receiver determines that a peek should not beissued, the receiver proceeds to step 446. Otherwise, in step 444 thereceiver outputs a peek request to multi-threaded FIFO memory 200 andoutputs the threadID for the thread via receiver threadID 231. Thereceiver may also provide an offset indicating that an entry other thanthe head of a thread FIFO should be read. Note that a take request willcause the read pointer to increment, whereas a peek request will notcause the read pointer to change.

In step 446 the receiver determines if data read for a peek or takerequest (present or at an earlier time) for the threadID should beremoved from multi-threaded FIFO storage 220 using a commit request,and, if not, the receiver proceeds directly to step 450. Otherwise, instep 447 the receiver asserts receiver commit 247 and in step 448 thereceiver decrements a committed credit for the threadID. The receivermaintains a committed credit count in addition to an available receivercredit count for each threadID in order to properly restore credits whena rollback is requested for the threadID. In step 450 the receiverdecrements the available receiver credit count for the threadID. Thereceiver has the flexibility to determine when to take data frommulti-threaded FIFO memory 200 for any one of the threads. Therefore,each of the threads may be processed independently from the otherthreads. Specifically, each thread may be processed as though a separateFIFO is used to store data for each thread.

FIG. 5A illustrates a conceptual diagram of a thread pointer list,thread pointer list 500, and FIFO storage 220 in accordance with one ormore aspects of the present invention. Thread pointer list 500 isincluded within read and write control 225 and may include flip-flops,RAM, or the like. Thread pointer list 500 includes an entry for eachentry in FIFO storage 220 that stores data for a particular thread andis used to configure FIFO storage 220 as a FIFO storing the data for theparticular thread.

Because FIFO storage 220 stores data for multiple execution threads thatpush and pop data at different rates, each entry in FIFO storage 220 maystore data for any one of the execution threads as the entry becomesavailable. Therefore, data for a single thread may be scattered withinvarious locations in FIFO storage 220. To emulate a FIFO for a singlethread, an ordered list of pointers for the single thread is maintainedusing thread pointer list 500. Thread base address 501 indicates thehead of the FIFO that stores a pointer to the entry that should be readby a take request, i.e., thread base address 501 is the read pointer. Asshown in FIG. 5A, thread base address 501 points to an entry in threadpointer list 500 that stores a pointer to entry2 512. Pointer to entry2512 points to an entry in FIFO storage 120 that contains thread data521.

Thread rollback address 502 indicates the entry of the FIFO that storesa pointer to the first-in data, i.e., thread rollback address 502 is therollback pointer. As shown in FIG. 5A, thread rollback address 502points to an entry in thread pointer list 500 that stores a pointer toentry2 510. Pointer to entry0 510 is stored in the first entry of threadpointer list 500 and points to an entry in FIFO storage 120 thatcontains thread data 523. The rollback pointer is incremented for eachreceiver commit request and the read pointer is incremented for eachreceiver take request. The read pointer is set to point to the sameentry as the rollback pointer when a receiver rollback request isreceived in order to replay output of any “taken” entries that have notbeen committed.

Thread reject address 504 indicates the entry of the FIFO that stores apointer to the last (newest) data that has been committed, i.e., threadreject address 504 is the reject pointer. As shown in FIG. 5A, threadreject address 504 points to an entry in thread pointer list 500 thatstores a pointer to entryN−2 518. Pointer to entryN−2 518 is stored inthe N−2 entry of thread pointer list 500 and points to an entry in FIFOstorage 120 that contains thread data 524. The reject pointer isincremented for each sender commit request. When each sender valid datawrite is committed, thread reject address 504 will point to pointer toentryN 520. The entries in thread pointer list 500 that are “newer” thanthread reject address 504, e.g., pointer to entry N−1 519 and pointer toentry N 520, are discarded when a sender reject request is received inorder to prevent reading by the receiver of any written entries thathave not been committed by the sender.

The second entry in the FIFO, thread data 529, is stored at the entry inFIFO storage 220 corresponding to pointer to entry1 511. Pointer toentry1 511 is stored in the second entry of thread pointer list 500, theentry offset by 1 from thread rollback address 502. The pointers storedin thread pointer list 500 are stored in FIFO order, the order in whichdata stored in the entry of FIFO storage 220 corresponding to thepointers was stored. For example, a third entry in the FIFO, the entryoffset by 2 from thread rollback address 502, stores pointer to entry2512 that corresponds to the entry in FIFO storage 220 that stores threaddata 521. The tail of the FIFO stores pointer to entryN 520, the entryoffset by N from thread rollback address 502, where N is the number ofoccupied entries in the FIFO. Pointer to entryN 520 corresponds to theentry in FIFO storage 220 that stores thread data 528. Thread data 522may be thread data for another thread or thread data that may beoverwritten because a pointer corresponding to the entry storing threaddata 522 is not stored in thread pointer list 500 or another threadpointer list.

As thread data is read from FIFO storage 220 using a take request,thread base address 501 is updated to point to the entry storing pointerto entry3 513, the entry storing pointer to entry4 514, and so forth. Asthread data is popped from FIFO storage 220, thread rollback address 502is updated to point to the entry storing pointer to entry1 511, theentry storing pointer to entry2 512, and so forth. Alternatively, eachpointer may be copied, i.e., shifted, to the adjacent entry in threadpointer list 500. For example, when pointer to entry0 510 is popped,pointer to entry1 511 may be copied to the entry corresponding to threadrollback address 502 and pointer to entry2 512 may be copied to theentry at an offset of 2. Shifting the pointers in thread pointer list500 may be more efficient than shifting the thread data stored in FIFOstorage 220 since the pointers are typically fewer bits than the threaddata. When data for multiple execution threads is stored in FIFO storage220, a thread pointer list is needed for each one of the multipleexecution threads, as shown in FIG. 5B.

FIG. 5B illustrates a conceptual diagram of a base address storage,rollback address storage 505, and an ordered pointer list, orderedpointer list 540, that includes a free entry pointer list and severalthread pointer lists, in accordance with one or more aspects of thepresent invention. Ordered pointer list 540 includes thread pointerlists for two or more execution threads and a free entry pointer list539 that stores pointers to entries in FIFO storage 220 that areavailable to store data. Because ordered pointer list 540 includes twoor more ordered pointer lists, a mechanism for locating the orderedpointer list for each thread should be provided. As previouslydescribed, a thread pointer list forms the data FIFO for an executionthread. The head of the data FIFO for a thread may be located using therollback address for the thread. The tail of the data FIFO for thethread may be located by subtracting 1 from the rollback address of thenext thread. For the last thread, the tail may be located by subtracting1 from the base address of free entry pointer list 539, free list baseaddress 509. In other embodiments of the present invention, addressesfor the tail locations may be stored or the addresses for the taillocations may be computed using the size of each data FIFO. The size ofeach data FIFO is easily determined by tracking the writes, rejects, andpops for each threadID.

Rollback address storage 505 includes an entry for a thread rollbackaddress of each one of the thread pointer lists and an entry for a baseaddress of a free list, free list base address 509. For example, thread0rollback address 502 is stored in a first entry of rollback addressstorage 505, thread1 rollback address 503 is stored in a second entry ofrollback address storage 505, threadN rollback address 508 is stored inan N+1 entry of rollback address storage 505, and free list base address509 is stored in the last entry of rollback address storage 505. A FIFOfor a particular threadID is empty when the rollback address for thethreadID is equal to the rollback address for the threadID+1. Inembodiments of the present invention that track the head and tail of theFIFO for each threadID, a FIFO is empty when the head is equal to thetail.

Reject address storage 550 includes an entry for a thread reject addressof each one of the thread pointer lists, e.g., thread0 reject address504 for thread0 pointer list 530, thread1 reject address 555 for thread1pointer list 531, and threadN reject address 558 for threadN pointerlist 538. Base address storage 560 includes an entry for a thread baseaddress of each one of the thread pointer lists, e.g., thread0 baseaddress 501 for thread0 pointer list 530, thread1 base address 561 forthread1 pointer list 531, and threadN base address 568 for threadNpointer list 538.

Upon reset, all of the entries in ordered pointer list 540 are includedin free entry pointer list 539. As thread data is pushed intomulti-threaded FIFO memory 200, free entries are moved from free entrypointer list 539 to the thread pointer lists. For example, when data ispushed into FIFO storage 220 of multi-threaded FIFO memory 200 forthread0, a pointer stored in the tail of free entry pointer list 539,free entry 545, is moved to the tail of thread0 pointer list 530, and isstored as pointer to entryJ 541. Alternatively, free entry 544 from thehead of free entry pointer list 539 may be moved to the tail of thread0pointer list 530 and stored as pointer to entryJ 541. When an entry ismoved within ordered pointer list 540, one or more rollback addresses,reject addresses, and base addresses may need to be changed. Forexample, when data is pushed into the FIFO for thread0, thread1 rollbackaddress 503 is changed, i.e., incremented, to point to the entry storingpointer to entry0 542 within thread1 pointer list 531. Likewise, threadNrollback address 508 and free list base address 509 are also changed.

When an entry is moved from free entry pointer list to a thread pointerlist, e.g., thread0 pointer list 530, thread1 pointer list 531, orthreadN pointer list 538, entries “above” the moved entry are shiftedup, so that each entry of ordered pointer list 540 is occupied and eachentry within a thread pointer list remains in FIFO order. The entriesare shifted up to absorb the removed entry in free entry pointer list539, e.g., free entry 545. Note, that the order of the entries in freeentry pointer list 539 is arbitrary. Therefore, any entry in free entrypointer list 539 may be moved when thread data is pushed. Similarly, anentry freed when thread data is popped may be inserted into any positionwithin free entry pointer list 539.

When data is popped (committed) from FIFO storage 220 of multi-threadedFIFO memory 200 for thread1, a pointer stored in the head of thread1pointer list 531, specifically at thread1 base address 503, is movedfrom thread1 pointer list 531 to free entry pointer list 539. Pointer toentry0 542 may be moved to the head or tail of free entry pointer list539. When an entry in a thread FIFO is popped, and the correspondingpointer the entry is popped from a thread pointer list, such as pointerto entry0 542, entries “above” the popped pointer are shifted down, sothat each entry of ordered pointer list 540 is occupied. Then the poppedpointer may be moved to an entry in free entry pointer list. Aspreviously explained with regard to pushing data, when data is poppedone or more rollback, reject, and base addresses may need to be updated,e.g. decremented.

When a multi-ported memory is used for FIFO storage 220, a pop and pushmay occur simultaneously. Therefore, in addition to moving a firstpointer from free entry pointer list 539 to a thread pointer list, asecond pointer may be moved from the thread pointer list or anotherthread pointer list to free entry pointer list 539. When data is pushedand popped from a one thread FIFO and one thread pointer list, therollback, reject, and base addresses are not changed and only entrieswithin the thread pointer list are shifted. Otherwise, some entries inordered pointer list 540 may be shifted up while other entries inordered pointer list 540 are shifted down.

FIG. 5C illustrates another conceptual diagram of ordered pointer list540 in accordance with one or more aspects of the present invention.When data for a thread is popped using a receiver commit request, thedata is read and output from the head of the data FIFO for the thread.When a non-zero offset is provided with a take request, the data is readand output from the entry in the data FIFO corresponding to a sum of thebase address for the thread and the offset. For example, when a take orpeek request for thread1 is received by multi-threaded FIFO memory 200with an offset, the offset is summed with thread1 rollback address 503to produce thread1 entryK 504. Thread1 entryK 504 corresponds to theentry of thread1 pointer list 531, i.e., the K+1 entry in the thread1FIFO, that stores pointer to entryK 543.

When the data stored in the entry of FIFO storage 220 corresponding topointer to entryK 543 is requested using a take (when speculative readsare not supported), pointer to entryK 543 is moved from thread1 pointerlist 531 to free entry pointer list 539. When speculative reads aresupported, the pointer to entryK 543 remains in thread1 pointer list 531until entryK 543 is committed. Specifically, when the data stored in theentry of FIFO storage 220 corresponding to pointer to entry0 542 isrequested using a receiver commit, pointer to entry0 542 is moved fromthread pointer list 531 to free entry pointer list 539.

FIG. 6A illustrates a flow diagram of an exemplary method of performingstep 350 shown in FIG. 3A, in accordance with one or more aspects of thepresent invention. In step 350 thread data is pushed into multi-threadedFIFO memory 200. In step 600, read and write control 225 obtains freelist base address 509 from rollback address storage 505. In step 605read and write control 225 reads a free list pointer from free entrypointer list 539. The free list pointer may be read from the head entryof free entry pointer list 539 using free list base address 509 or fromanother entry within free entry pointer list 539. In step 610 read andwrite control 225 writes the thread data to the entry in FIFO storage220 that corresponds to the free list pointer.

In step 615 read and write control 225 obtains the thread rollbackaddress for the threadID included with the thread data that was pushed.The thread rollback address is read from rollback address storage 505.In step 620 the free list pointer is moved from free entry pointer list539 to the thread pointer list that corresponds to the threadID bystoring the free list pointer in the entry of ordered pointer listcorresponding to the thread rollback address for the threadID+1. Theentry storing the free list pointer becomes the tail of the thread FIFOfor the threadID. In step 620 read and write control 225 shifts entriesin ordered pointer list 540 as needed to move the free list pointer tothe thread pointer list and proceeds to step 345.

FIG. 6B illustrates a flow diagram of an exemplary method of performingstep 352 shown in FIG. 3C, in accordance with one or more aspects of thepresent invention. In step 352 thread data is committed to FIFO storage220 in response to a sender commit request. In step 627 the threadreject address for the threadID is updated by incrementing the threadreject address in the thread pointer list for threadID. In step 629sender interface 210 outputs a push to read and write control 225. Readand write control 225 outputs the push signal to receiver interface 230in order to generate a receiver credit for the threadID.

FIG. 6C illustrates a flow diagram of an exemplary method of performingstep 415 shown in FIG. 4A in accordance with one or more aspects of thepresent invention. In step 415 thread data is read from FIFO storage 220in response to a peek or take request. In some embodiments of thepresent invention, an offset is not provided by the receiver with thetake request.

In step 630 read and write control 225 obtains the thread base addressfor the threadID included with the take request. The thread base addressis read from base address storage 560. In step 645 the pointercorresponding to the first entry in FIFO storage 220 (the head of theFIFO) for the threadID is read from the entry of the pointer list withinordered pointer list 540 that corresponds to the thread base address. Instep 650 the thread data is read from the entry in FIFO storage 220 thatcorresponds to the pointer. In step 670 the thread data is output to thereceiver via receiver interface 230 and read and write control 225proceeds to step 417.

FIG. 6C illustrates a flow diagram of another exemplary method ofperforming step 420 shown in FIGS. 4A and 4C in accordance with one ormore aspects of the present invention. In this embodiment of the presentinvention, an offset may be provided by the receiver with the takerequest.

In step 660 read and write control 225 updates the base addresses, oneor more thread base addresses and/or free list base address 509, asneeded. For example, the thread base address for threadID+1 is updatedby decrementing the thread base address to accommodate the popped entryin the thread pointer list for threadID. Likewise, free list baseaddress 509 is also decremented since an entry will be inserted in freeentry pointer list 539. In step 665 the pointer is moved from the threadpointer list that corresponds to the threadID to free entry pointer list539. In step 665 read and write control 225 also shifts entries inordered pointer list 540 as needed to move the pointer to free entrypointer list 539.

Step 630 is completed as previously described to obtain the thread baseaddress for the threadID included with the take request. In step 635read and write control 225 determines if a non-zero offset is providedwith the take request, and, if not, read and write control 225 proceedsto complete steps 645, 650, 660, 665, and 670 as previously described inconjunction with FIG. 6B. Otherwise, in step 640 the pointercorresponding to the entry in FIFO storage 220 for the threadID is readfrom the entry of the thread pointer list within ordered pointer list540 that corresponds to the sum of the thread base address and offset.Steps 645, 650, 660, 665, and 670 are completed as previously describedin conjunction with FIG. 6B.

FIG. 6D illustrates a flow diagram of an exemplary method of performingstep 420 shown in FIG. 4A in accordance with one or more aspects of thepresent invention. In this embodiment of the present invention, anoffset may be provided by the receiver with a take request or a peekrequest. In step 420 thread data is committed and removed from FIFOstorage 220 in response to a receiver commit request.

In step 655 receiver interface 230 determines if a rollback request isreceived, and, if so, in step 657 read and write control 225 sets thethread base address to the rollback address to restore any read, but notcommitted entries for the threadID, before proceeding to step 425.Otherwise, in step 660 read and write control 225 updates the baseaddress for the thread specified by receiver threadID 231 byincrementing the base address to point to the next entry for the thread.

In step 662 read and write control 225 determines if a receiver commitrequest is received, and, if not, then read and write control 225proceeds directly to step 425. Otherwise, in step 665 read and writecontrol 225 moves the pointer stored at the thread rollback addresscorresponding to the threadID to free entry pointer list 539. In step665 read and write control 225 shifts entries in ordered pointer list540 as needed to move the pointer from the thread pointer list to thefree list pointer and proceeds to step 667. In step 667 read and writecontrol 225 updates the thread rollback address corresponding to thethreadID by incrementing it to point to the next oldest entry in thepointer list for the threadID and then proceeds to step 425.

The current invention involves new systems and methods for storing datafor multi-threaded processing. Instead of using a separate FIFO memoryto store data for each thread, a single memory, FIFO storage 220, isused to store data for multiple threads. The single memory is sharedbetween the threads to conserve die area, however each thread may beexecuted independently, as if each thread has a dedicated FIFO memory.An ordered list of pointers for each thread is maintained to emulate aFIFO for the multiple execution threads. Speculative read and writecapability may be included to allow FIFO storage 220 to read and writedata and later pop and push the FIFO entries. Persons skilled in the artwill appreciate that any system configured to perform the method stepsof FIG. 1C, 1D, 1E, 1F, 1G, 3A, 3B, 3C, 4A, 4B, 6A, 6B, 6C, or 6D, ortheir equivalents, is within the scope of the present invention.

The current invention also involves new systems and methods forefficiently producing different variations of FIFO memories. Inparticular, a synthesizable code generator may be used to produce FIFOmemories for multi-threaded processing. The synthesizable code generatorproduces synthesizable code for a sender interface, storage, receiverinterface, and other features that are specified by a programmer. Inputsto the synthesizable code generator may be used to specify definedoptions for the sender interface, storage, and receiver interface. Theseoptions include a request/busy interface, a credit based interface,immediate credits, a take based interface, adding ports, removing ports,the type of storage devices, storage bypass, peek request logic, readoffset logic, speculative write logic. Other features may also bespecified using inputs to the synthesizable code generator. Thesefeatures include an asynchronous interface to transfer signals betweendifferent clock domains, gating clock(s) to reduce power, and addingregisters to input and/or output signals to improve timing.

While the foregoing is directed to embodiments of the present invention,other and further embodiments of the invention may be devised withoutdeparting from the basic scope thereof, and the scope thereof isdetermined by the claims that follow. The foregoing description anddrawings are, accordingly, to be regarded in an illustrative rather thana restrictive sense. The listing of steps in method claims do not implyperforming the steps in any particular order, unless explicitly statedin the claim.

All trademarks are the respective property of their owners.

1. A method of storing data for multiple execution threads in a FIFO(first-in first-out memory) storage, comprising: issuing a sender creditto a sender indicating that at least one entry is available in the FIFOstorage to store the data; receiving data for a first thread of themultiple execution threads from the sender; obtaining a pointer to anentry in the FIFO storage from a free pointer list that includespointers to entries in the FIFO storage that are available to store datafor the multiple execution threads; storing the data in the entry;storing the pointer in a list of pointers corresponding to the firstthread, wherein each thread is associated with a corresponding list ofpointers, and each list of pointers is ordered above a previous list ofpointers to form an ordered list of pointers for the multiple executionthreads; and incrementing a rollback address, a base address, and areject address for each thread that is above the first thread in theordered list of pointers, wherein the rollback address indicates anoldest entry in the ordered list of pointers that has not been poppedfor a corresponding thread, the base address indicates an entry in theordered list of pointers that stores a next entry to read for acorresponding thread, and the reject address indicates a newest entry inthe ordered list of pointers that has been committed for a correspondingthread.
 2. The method of claim 1, further comprising receiving a sendercommit request from the sender indicating that a receiver is allowed toread the data from the FIFO storage.
 3. The method of claim 2, furthercomprising incrementing a reject address that indicates a newest entryin the FIFO storage for the first thread that has been committed by thesender.
 4. The method of claim 2, further comprising outputting areceiver credit to the receiver indicating that the data for the firstthread is stored in the FIFO storage.
 5. The method of claim 4, furthercomprising: receiving a take request from the receiver for the firstthread; obtaining the pointer from the ordered list of pointers; readingthe data from the entry in the FIFO storage using the pointer; andoutputting the data to the receiver.
 6. The method of claim 5, furthercomprising incrementing a base address for the first thread thatindicates a next entry in the FIFO storage to be read for the firstthread.
 7. The method of claim 6, further comprising: receiving arollback request for the first thread; and setting the base address forthe first thread equal to a rollback address for the first thread toallow the entry in the FIFO storage to be read again.
 8. The method ofclaim 5, further comprising: receiving a receiver commit request fromthe receiver for the first thread; and moving the pointer from theordered list of pointers to the free pointer list.
 9. The method ofclaim 8, further comprising decrementing the rollback address, the baseaddress, and the reject address for the second thread that is above thefirst thread in the ordered list of pointers.
 10. The method of claim 8,further comprising incrementing a rollback address for the first threadthat indicates a next entry in the FIFO storage to be committed for thefirst thread.
 11. The method of claim 1, further comprising: receiving areject request from the sender for the first thread; and moving thepointer from the ordered list of pointers to the free pointer list toremove the data from the FIFO storage for the first thread.
 12. Themethod of claim 11, further comprising decrementing the rollbackaddress, the base address, and the reject address for the second threadthat is above the first thread in the ordered list of pointers.
 13. Asystem for storing data for multiple execution threads, comprising: asender interface configured to receive the data for the multipleexecution threads from a sender; a FIFO (first-in first-out memory)storage coupled to the sender interface and configured to store the datafor the multiple execution threads; a receiver interface coupled to theFIFO storage and configured to output data from the FIFO storage to areceiver; a list of pointers coupled to the FIFO storage and configuredto store free pointers corresponding to entries in the FIFO storage thatare available to store data in a first portion and to store pointerscorresponding to entries in the FIFO storage that store data for themultiple execution threads in a second portion, wherein each thread ofthe multiple execution threads is associated with a corresponding listof pointers in the second portion, and each list of pointers for aparticular thread is ordered above a list of pointers for a differentthread to form an ordered list of pointers for the multiple executionthreads; a thread base address list configured to store a base addressindicating an entry in the ordered list of pointers that stores a nextentry to read for a corresponding thread; and a thread rollback addresslist configured to store a rollback address indicating an oldest entryin the ordered list of pointers that has not been popped by the receiverfor a corresponding thread; and a thread reject address list configuredto store a reject address indicating a newest entry in the ordered listof pointers that has been committed by the sender for a correspondingthread.
 14. The system of claim 13, wherein the second portion includesa set of pointers for a first thread and the pointers for the firstthread are stored in consecutive adjacent entries within the secondportion in an order that the pointers are used to write data for thefirst thread in the FIFO storage.
 15. The system of claim 14, wherein abase address for the first thread is incremented when data for the firstthread is read and output to the sender.
 16. The system of claim 14,wherein a rollback address for the first thread is incremented when datafor the first thread is committed by the receiver and a pointer is movedfrom the second portion of the ordered list of pointers to the firstportion of the ordered list of pointers.
 17. The system of claim 15,wherein the base address for the first thread is set to equal a rollbackaddress for the first thread when a rollback request for the firstthread is received from the sender.
 18. The system of claim 13, whereina reject address for a first thread is incremented when data stored inthe FIFO storage is committed by the sender and a receiver credit isoutput to the receiver indicating that the data for the first thread isavailable to be read.
 19. The system of claim 13, wherein a pointer ismoved from the second portion of the ordered pointer list to the firstportion of the ordered pointer list to remove data for the first threadfrom the FIFO storage when a reject request is received from the senderfor the first thread.